Week 2, Day 2 — MFA enforcement & authentication methods

Day 1 review & the next gap

Bridge from role assignments into authentication — the roles are set, but the accounts are still protected only by passwords.

• Quick check: ask two students to name a role they assigned yesterday and what that role can and cannot do — no notes
• Ask: "Sarah Chen now has User Administrator. Her account is protected by a password. What does an attacker need to compromise the entire Lakeview Logistics user base?" — answer: just Sarah's password
• Ask: "What is MFA and how does a second factor help even if a password is stolen?" — students should know this conceptually; surface it before building on it
• Frame the day: today every Lakeview Logistics user gets MFA. Not just admins — everyone. The weakest account is the attacker's entry point.

Authentication methods in Microsoft 365 — the full picture

MFA is not a single setting — it is a policy built from a set of authentication methods, each with different security properties and user experience trade-offs. Students need to understand the options before they configure anything.

• The authentication methods policy — in Entra ID, authentication methods are managed centrally via the Authentication methods policy (entra.microsoft.com → Protection → Authentication methods). This is the single place that controls which methods are available tenant-wide. Individual policies for specific users or groups are configured within it.
• The method landscape — know what each one is:

• Per-user MFA vs policy-driven MFA — per-user MFA (the legacy approach) enables MFA on individual accounts directly. Policy-driven MFA (via Conditional Access) applies MFA based on conditions — who is signing in, from where, on what device. Conditional Access is covered in Day 3. Today students use per-user MFA because it works on Business Standard without Conditional Access policies, and because understanding the legacy approach helps when they encounter it in production environments.
• Security defaults — Microsoft's pre-configured baseline security policy. When enabled, it forces MFA registration for all users, blocks legacy authentication, and requires MFA for all admin sign-ins. It is a blunt instrument — good for organisations with no existing CA policies, but it cannot coexist with Conditional Access. Students will see this today and understand why it is disabled in favour of more granular control.
• MFA registration vs MFA enforcement — these are different states. A user can be registered for MFA (they have a method configured) but not enforced (they are not required to use it). Enforcement requires either per-user MFA state set to Enabled/Enforced or a Conditional Access policy requiring it. Registration without enforcement gives users the option — enforcement makes it mandatory.
• Number matching and additional context — Microsoft Authenticator push notifications can show the number displayed on the sign-in screen for the user to match, preventing MFA fatigue attacks where an attacker repeatedly pushes notifications hoping the user approves one. These settings are in the Authentication methods policy and should always be enabled.
• Passwordless authentication — the long-term direction. Microsoft Authenticator, FIDO2 keys, and Windows Hello are all passwordless-capable methods. Passwordless eliminates the password as an attack surface entirely. Worth introducing now even if not fully deployed in this lab.

Lab 2-B: Configuring and enforcing MFA for Lakeview Logistics

Students configure the authentication methods policy, enable and configure Microsoft Authenticator with number matching, enforce per-user MFA for all Lakeview Logistics users, register MFA on their own admin account, test the sign-in experience, and review the MFA registration report.

• Step 1 — Review Security defaults (5 min)
  Navigate to entra.microsoft.com → Overview → Properties → Manage security defaults. Check whether Security defaults are enabled or disabled. If enabled, disable them — Security defaults cannot coexist with per-user MFA enforcement or Conditional Access policies. Record the current state in your Lab Journal before making any change.
• Step 2 — Configure the authentication methods policy (15 min)
  Navigate to entra.microsoft.com → Protection → Authentication methods → Policies. Configure the following:

• Step 3 — Enable per-user MFA for all Lakeview Logistics users (10 min)
  Navigate to entra.microsoft.com → Protection → Multifactor authentication → Per-user MFA (or via the legacy portal link: aka.ms/mfasetup / account.activedirectory.windowsazure.com/usermanagement/mfasettings.aspx).
  
  Select all 10 Lakeview Logistics users. Click Enable. Confirm the action. All users should now show status as Enabled. Record the before and after states in your Lab Journal.
• Step 4 — Register MFA on your own admin account (15 min)
  Open a private browser window and sign in to aka.ms/mysecurityinfo using your Global Admin account. You will be prompted to register a security method. Register Microsoft Authenticator on your personal phone:
  · Download the Microsoft Authenticator app if not already installed
  · Add a work/school account in the app
  · Scan the QR code shown on screen
  · Complete the number matching test push notification
  
  After registering Authenticator, also register your phone number as a backup SMS method. Record both registered methods in your Lab Journal.
• Step 5 — Test the MFA sign-in experience (10 min)
  Sign out of your Global Admin account completely. Sign back in to admin.microsoft.com. You should be prompted for MFA after entering your password. Complete the Authenticator push notification — note the number matching prompt. Record the full sign-in flow in your Lab Journal, including exactly what screens appeared and in what order.
• Step 6 — Issue a Temporary Access Pass for Dev Sharma (10 min)
  Dev Sharma has just got a new phone and cannot access his Authenticator app. Navigate to entra.microsoft.com → Users → All users → Dev Sharma → Authentication methods → Add authentication method → Temporary Access Pass. Generate a TAP with a 2-hour lifetime. Record the TAP value and expiry time in your Lab Journal.
  
  In a private browser window, use the TAP to sign in as Dev Sharma at mysignins.microsoft.com and navigate to aka.ms/mysecurityinfo to register a new authentication method. Record what happens.
• Step 7 — Review the MFA registration report (10 min)
  Navigate to entra.microsoft.com → Protection → Authentication methods → User registration details. Review the registration state of all users. Record: how many users are MFA-capable? How many are registered vs not registered? Which methods are most commonly registered?

⭐ Bonus: MFA fraud alert & registration campaign

For students who complete the core lab early. Two independent extension tasks.

Reflection & preview

• Ask: "All 10 users now have MFA enabled. But enabled is not the same as enforced and registered — what is the difference, and what happens when a user with MFA enabled but not registered tries to sign in?"
• Ask: "Why did we disable voice call as an authentication method? What makes SMS only slightly better?" — reinforce the method security hierarchy
• Ask: "You issued Dev Sharma a Temporary Access Pass. It expires in 2 hours. What happens if Dev doesn't register a new method before it expires?" — surface the operational planning aspect of TAPs
• Collect exit ticket: explain the difference between per-user MFA and Conditional Access-based MFA — when would you use each, and which is preferable for a growing organisation?
• Preview Day 3: MFA is now available for all users — but it applies equally to every sign-in from everywhere. Day 3 introduces Conditional Access, which lets you apply MFA selectively based on conditions: who is signing in, from where, on what device, and with what risk level